1. Field of the Invention
This invention relates to the field of programmable logic devices, and more particularly relates to a method and system for identifying the essential configuration bits of a design.
2. Description of the Related Art
In creating a design that is to be programmed into a programmable logic device (PLD), a designer employs a program tasked with generating the configuration bits representing the design (referred to as a configuration bitstream generation module, or the like), among other such design tools. A configuration bitstream generation module determines the value of each configuration bit used in the design, based on a description of the circuit being implemented. Such a circuit description typically includes logic elements, logical connections and other such information.
Typically, the set of configuration bits used by a given design is only a subset of the total number of configuration bits in the programmable logic device being programmed. These “essential” or “care” configuration bits configure the resources used in implementing the logic elements that make up the given design (such as look-up tables (LUTs), multiplexers, programmable interconnect points (PIPs) and the like) by defining the function(s) implemented by those resources. Some of these essential configuration bits (or more simply, essential bits) may be set (e.g., to a logic one), while others are allowed to retain their default configuration value (e.g., a logic zero). While the value of the latter are the same as unused configuration bits, such essential bits are nonetheless necessary to implement the given design. As will be appreciated, essential configuration bits that retain their default value are therefore difficult to distinguish from unused configuration bits.
Often, however, a project will require the identification or count of the design's essential bits, and so present a fairly intractable problem. As just noted, this cannot be determined simply by comparing the bitstream generated with a blank bitstream because their difference will not evidence all the design's essential configuration bits, but only those configuration bits with altered values (which, as will be appreciated, are relatively straightforward to discern). Moreover, determining which configuration bits are used in a given design also requires the solution to another problem, namely the functional grouping of configuration bits.
Heretofore, a combination of various tools and manual operations have been used to provide such identification. However, these approached have suffered from a variety of infirmities. For example, such a tool chain may be able identify a large portion of the essential bits of a design, but with limited accuracy, or may be able to identify only a small subset of the essential bits, albeit with acceptable accuracy. Moreover, such approaches can require significant resources (e.g., requiring the grouping of configuration bits be performed manually, when attempting to coordinate configuration bits and logic elements).
One approach identifies essential bits using a process that begins with the creation of a circuit description database by the design environment's implementation tools. Such a database represents the physical view of a programmable logic device's design (e.g., an FPGA design). The design's circuit description database is input to a program that identifies the routing resources used, and then a tool that identifies the logic resources used (referred to as a logic resource identifier).
The output of the logic resource identifier is input to a script that accesses a database generated from the configuration data model. The output of this script and the routing resources file are read by a design extractor. The design extractor maps the wire resources to the respective configuration bits by using a wire database. The location of wire and logic bits within the bitstream is also determined for the target device.
Practical issues arise when using a tool chain such as that described above. One limitation is that an assortment of environments and tools are required: stand-alone programs, scripts, database engines and other design environment tools. Support for these tools may need to be distributed across several divisions/groups within an organization. Moreover, file sizes, memory requirements and execution times can be considerable for large designs when using such an approach.
In many cases, such a tool chain is also limited in the number of architectures that can be supported. This is due, in part, to the fact that developing and validating a model for a new architecture using such an approach is a great deal of work. Although scripts can be used to automatically generate some of the requisite information from device model files, substantial manual work is still required for logic resources. Such tools are required to have complete tile and configuration bit coverage, which is not normally required in other uses of such tools. Such coverage can also be difficult to achieve and verify. The effort involved is compounded by the large number of tile types in some architectures.
Configuration bits can also be affected by run-time options used by the configuration bitstream generator, as well as the structure of the configuration bitstream generator's internal code. Moreover, configuration bits are often not captured in the circuit descriptions used to describe the circuit being implemented. Although most of these options affect the startup process, they are sometimes used for other purposes, and so their effects may go unnoticed or undetected.
What is therefore desired is an approach that addresses the foregoing infirmities. Preferably, such an method and system should provide such capabilities as part of a standard design flow.